今日主題：

軟體系統能夠工作比較重要，還是軟體系統更容易變更比較重要？

能夠工作 = 房間能整理好
意思是：至少東西有歸位，暫時能住人、能用。就像軟體能跑起來，先解決眼前需求。

容易變更 = 房間容易打掃
意思是：之後要換擺設方式、清潔、收納，都很方便，不會變成下次整理的大災難。就像軟體架構設計良好，未來能輕鬆修改。

小故事：

阿吉的房間又亂了。桌上有漫畫書，床上有衣服，書包裡塞滿昨天收回來已經考完的考卷。
這次他決定試試兩種整理方法：

1. 快速整理法
   他把漫畫疊起來放到桌角，衣服塞進衣櫃，考卷隨便塞在放紙類的箱子。房間看起來整齊了，至少可以讓媽媽進來檢查時不會被念。

2. 耐心整理法
   他先把書櫃清空，分好漫畫區、參考書區，再幫衣服褲子折好放不同層的衣櫃。考卷分類放到資料夾。雖然一開始花了比較久，但下次要找東西就超快。

過了一個星期，第一種方法的房間又亂了，東西找不到，阿吉只好再來一次大掃除。第二種方法的房間，卻只要花五分鐘就能恢復整齊。

阿吉忽然想到，原來寫程式也一樣：

• 「能跑起來」就像快速整理法，先解決眼前的需求。
• 「容易維護」就像耐心整理法，未來才不會一直掉進無止盡的大掃除。

今天的實驗：

我試了兩種不同建立專案的方式：

1. 請 Copilot 幫我生出最簡單的後端功能，然後連上 Supabase 資料庫。
2. 開好前端（前台＋後台）、後端，並把需求描述丟給 ChatGPT，請 AI 幫我設計 prompt。

結果：

• 第一個方式，前端只有簡單的 HTML。
• 第二個方式，後端直接用 NextJS 加 PostgreSQL，前端則是 Nuxt.js。

一開始的 Prompt 設計方式不同，產生出來的「規模」與「步驟」差超多！
第一種方法，很快就能看到新增、標記分類、搜尋的功能，甚至有圖片。

在程式中的應用

我今天還在 .github/copilot-instruction.md 裡，參考了 Kent Beck 老師在 GitHub 上的 B+Tree 專案，學到一個「Tidy First 方法」：

TIDY FIRST APPROACH | Tidy First 方法
將所有變更分成兩種明確類型：
STRUCTURAL CHANGES（結構性變更）：重新排列程式碼但不改變行為（重新命名、抽取方法、移動程式碼）
BEHAVIORAL CHANGES（行為性變更）：新增或修改實際功能
絕不在同一次提交中混合結構性與行為性變更
需要兩者時，先做結構性變更
透過測試驗證結構性變更前後行為不變

資料來源：Kent Beck 的 Claude Code 規則翻譯：TDD 與 Tidy First 的實踐指南

這就像「先把房間收納位置整理清楚，再決定要不要添購新東西」。

小結與思考問題：

• 你覺得阿吉下次要整理房間時，會選哪種方法？
• 下次繼續在寫程式的時候，有什麼需求是可以再加上去的？
• 目前兩個專案，如果只有「一個人＋一個 AI」來維護，覺得怎樣設計專案會更好調整呢？